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The EDNS(0) Padding Option 
Abstract 
This document specifies the EDNS(0) "Padding" option, which allows 


DNS clients and servers to pad request and response messages by a 
variable number of octets. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7830. 
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1. Introduction 


The Domain Name System (DNS) [RFC1035] was specified to transport DNS 
messages in cleartext form. Since this can expose significant 
amounts of information about the Internet activities of an end user, 
the IETF has undertaken work to provide confidentiality to DNS 
transactions (see the DPRIVE working group). Encrypting the DNS 
transport is considered one of the options to improve the situation. 


However, even if both DNS query and response messages were encrypted, 
metadata could still be used to correlate such messages with well- 
known unencrypted messages, hence jeopardizing some of the 
confidentiality gained by encryption. One such property is the 
message size. 


This document specifies the Extensions Mechanisms for DNS (EDNS (0) ) 
"Padding" option, which allows DNS clients and servers to 
artificially increase the size of a DNS message by a variable number 
of bytes, hampering size-based correlation of the encrypted message. 


2. Terminology 


The terms "Requestor" and "Responder" are to be interpreted as 
specified in [RFC6891]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 
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3. The "Padding" Option 


The EDNS (0) [RFC6891] specifies a mechanism to include new options in 
DNS packets, contained in the RDATA of the OPT meta-RR. This 
document specifies the "Padding" option in order to allow clients and 
servers to pad DNS packets by a variable number of bytes. The 
"Padding" option MUST occur at most, once per OPT meta-RR (and hence, 
at most once per message). 


The figure below specifies the structure of the option in the RDATA 
of the OPT RR: 


0 8 16 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- 
| OPTION-CODE | 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| OPTION-LENGTH | 
+--+--+--+--+--+--+--+--+--+--+--+--+--+-+H 
| (PADDING) ... (PADDING) ... / 


+— — — = as ea = = Pan — = = E pan; = = 


Figure 1 
The OPTION-CODE for the "Padding" option is 12. 


The OPTION-LENGTH for the "Padding" option is the size (in octets) of 
the PADDING. The minimum number of PADDING octets is 0. 


The PADDING octets SHOULD be set to 0x00. Other values MAY be used, 
for example, in cases where there is a concern that the padded 
message could be subject to compression before encryption. PADDING 
octets of any value MUST be accepted in the messages received. 


4. Usage Considerations 


This document does not specify the actual amount of padding to be 
used, since this depends on the situation in which the option is 
used. However, padded DNS messages MUST NOT exceed the number of 
octets specified in the Requestor’s Payload Size field encoded in the 
RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC6891]). 


Responders MUST pad DNS responses when the respective DNS query 
included the "Padding" option, unless doing so would violate the 
maximum UDP payload size. 


Responders MAY pad DNS responses when the respective DNS query 


indicated EDNS (0) support of the Requestor and the "Padding" option 
was not included. 
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Responders MUST NOT pad DNS responses when the respective DNS query 
did not indicate EDNS(0) support. 


5. IANA Considerations 


IANA has assigned Option Code 12 for "Padding" in the "DNS EDNSO 
Option Codes (OPT)" registry. 


IANA has updated the respective registration record by changing the 
Reference field to RFC 7830 and the Status field to "Standard". 


6. Security Considerations 


Padding DNS packets obviously increases their size, and will 
therefore lead to increased traffic. 


The use of the EDNS(0) padding only provides a benefit when DNS 
packets are not transported in cleartext. Further, it is possible 
that EDNS(0) padding may make DNS amplification attacks easier. 
Therefore, implementations MUST NOT use this option if the DNS 
transport is not encrypted. 


Padding length might be affected by lower-level compression. 
Therefore (as described in Section 3.3 of [RFC7525]), implementations 
and deployments SHOULD disable compression at the Transport Layer 
Security (TLS) level. 


The payload of the "Padding" option could (like many other fields in 
the DNS protocol) be used as a covert channel. 
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